In the field of electronics, various electronic design automation (EDA) tools are useful for automating the process by which integrated circuits, multi-chip modules, boards, etc., are designed and manufactured. In particular, electronic design automation tools are useful in the design of standard integrated circuits, custom integrated circuits (e.g., ASICs), and in the design of custom configurations for programmable integrated circuits. Integrated circuits that may be programmable by a customer to produce a custom design for that customer include programmable logic devices (PLDs). Programmable logic devices refer to any integrated circuit that may be programmed to perform a desired function and include programmable logic arrays (PLAs), programmable array logic (PAL), field programmable gate arrays (FPGA), complex programmable logic devices (CPLDs), and a wide variety of other logic and memory devices that may be programmed. Often, such PLDs are designed and programmed by an engineer using an electronic design automation (EDA) tool that takes the form of a software package.
Such an EDA tool is used to create source files having lines of source code that together specify a design to be programmed into a PLD. A given line of source code in a design file may produce many flip-flops, latches, or other gates. A line may also call a sub-function that in turn generates a number of logic elements. It is also possible that a line such as a flow control statement would not generate any logic elements. Knowledge of how many logic elements a given line of source code is generating is extremely useful to a designer. Once a designer knows which line of source code is generating the most logic elements or levels of logic (creating a greater timing delay), the designer may then attempt to optimize that line of source code.
More specifically, it is useful for a user creating a design for a PLD to know the area the design will occupy, the speed of the design, and how many memory elements the design will need. Area may be indicated by estimating a gate count, speed can be estimated by levels of gates a signal passes through, and memory elements estimated by counting numbers of flip-flops and latches required. This utilization information can help a designer in optimizing his or her design.
For example, it is also desirable to know how many flip-flops, latches or other memory elements the design will require. Often, certain ways of writing source code in a design language, or errors in the code may result in extra, unwanted memory elements. For a PLD with space constraints, unneeded memory elements are a problem. For example, the source statement "If A then B=C" would generate a latch because if A fails then B must hold its value. By contrast, the statement "If A then B=C, else B=D" would not generate a latch because the value of B always changes. If a user neglects to add an "else" clause (such as at the end of a long string of clauses), or does not use one when he could, extra latches would be generated.
Similarly, extra flip-flops may also be generated unbeknownst to the user. For example, in VHDL the following statements in a process block will generate only one flip-flop: if (clk' event and clk=`1`) then g:=f and c; c:=g; end if;. In these statements, c will become a flip-flop whereas g will not be flip-flop since it is read only after it is written to. This can be a surprise to the designer since subtle differences in where variable values are read or written determines which variables become flip-flops. Also in VHDL, latches may be inadvertently created by not assigning a value to a variable in every if/then/elseif/else section.
One software tool called "HDL Critic" available from Synopsys of Mountain View, Calif. is able to estimate number of gates for a design, flip-flops, and latches. (Other products called "HDL Advisor" and "RTL Analyzer" may also include this functionality.) Because the compiler available from Synopsys can take many hours to perform a synthesis, the HDL Critic tool does not perform its analysis during compilation (which would take a long time to get results), but is a separate module that analyzes a source file. It then displays estimated number of gates for each line of source code. However, because HDL Critic looks at a source file before compilation, and does not perform analysis during a compilation of the complete design, it is not as accurate as it could be.
HDL Critic is also able to produce information such as number of logic cells, number of levels, number of logic cells with flip-flops and latches, but performs this analysis after compilation. HDL Critic performs this analysis by using a "back annotation" command after a compile has completed. However, this analysis is not part of a compile.
Other difficulties exist with producing such utilization information. For example, in certain situations logic cells are produced during the synthesis stage of a compilation that do not correspond to any gate in the post-extraction netlist. In other words, there is no output gate that corresponds to the output of these logic cells. These are termed "synthesized" logic cells.
Because these cells are "synthesized" during synthesis, and do not correspond directly back to gates in the post-extraction netlist, it can be difficult to determine the corresponding lines of source code. By contrast, logic cells that have corresponding gates in the post-extraction netlist can be associated with lines of source code because these gates can be traced back to the lines of source code that produced them. As these synthesized logic cells still take up space in a PLD, it is important to take these cells into account when producing utilization information such as total number of logic cells produced by a line of source code, maximum path length through logic cells for a line of source code, etc.
Therefore, it would be desirable to have a technique and system by which utilization information for a PLD design is calculated accurately within the context of the complete PLD design and produces an accurate design profile for display to a user.